The present invention is generally directed to the redirection of USB Attached SCSI Protocol (UASP) devices in a virtual desktop infrastructure (VDI) environment. Device redirection generally refers to making a device that is connected to a client terminal accessible within a virtual desktop as if the device had been physically connected to the virtual desktop. In other words, when device redirection is implemented, a user can connect a device to his or her client terminal and the device will function as if it had been connected to the server.
FIGS. 1 and 2 and the following description will provide a general overview of how device redirection can be implemented in accordance with some embodiments of the present invention. In FIG. 1, a computing system 100 is depicted as including a number of client terminals 102a-102n (referenced generally herein as client(s) 102) in communication with a server 104 via a network 106. Server 104 can be configured to support a remote session (e.g., a remote desktop session) wherein a user at a client terminal 102 can remotely access applications and data at the server 104 from the client terminal 102. Such a connection may be established using any of several well-known techniques such as the Remote Desktop Protocol (RDP) and the Citrix® Independent Computing Architecture (ICA).
Client terminal 102 may represent a computer, a mobile phone (e.g., smart phone), a laptop computer, a thin client terminal, a personal digital assistant (PDA), a portable computing terminal, or a suitable terminal or device with a processor. Server 104 may represent a computer, a laptop computer, a computing terminal, a virtual machine (e.g., VMware® Virtual Machine), a desktop session (e.g., Microsoft Terminal Server), a published application (e.g., Microsoft Terminal Server) or a suitable terminal with a processor.
Client terminal 102 may initiate a remote session with server 104 by sending a request for remote access and credentials (e.g., login name and password) to server 104. If server 104 accepts the credentials from client terminal 102, then server 104 may establish a remote session, which allows a user at client terminal 102 to access applications and data at server 104. During the remote session, server 104 sends display data to client terminal 102 over network 106, which may include display data of a desktop and/or one or more applications running on server 104. The desktop may include, for example, icons corresponding to different applications that can be launched on server 104. The display data allows client terminal 102 to locally display the desktop and/or applications running on server 104.
During the remote session, client terminal 102 may send user commands (e.g., inputted via a mouse or keyboard at client terminal 102) to server 104 over network 106. Server 104 may process the user commands from client terminal 102 similar to user commands received from an input device that is local to server 104. For example, if the user commands include mouse movements, then server 104 may move a pointer on the desktop running on server 104 accordingly. When the display data of the desktop and/or application changes in response to the user commands, server 104 sends the updated display data to client terminal 102. Client terminal 102 locally displays the updated display data so that the user at client terminal 102 can view changes at server 104 in response to the user commands. Together, these aspects allow the user at client terminal 102 to locally view and input commands to the desktop and/or application that is running remotely on server 104. From the perspective of the client side, the desktop running on server 104 may represent a virtual desktop environment.
Windows I/O uses a layered architecture where device drivers are on a device stack. In a basic model, the top of the stack is the file system. Next is the volume manager, followed by the disk driver. At the bottom of the device stack are the port and miniport drivers. When an I/O request reaches the file system, it takes the block number of the file and translates it to an offset in the volume. The volume manager then translates the volume offset to a block number on the disk and passes the request to the disk driver. When the request reaches the disk driver it will create a Command Descriptor Block (CDB) that will be sent to the SCSI device. The disk driver imbeds the CDB into a structure called the SCSI13 REQUEST_BLOCK (SRB). This SRB is sent to the port driver as part of the I/O request packet (IRP).
The port driver does most of the request processing including providing timing services for requests, enforcing queue depth (making sure that a device does not get more requests that it can handle), and building scatter gather arrays for data buffers. The port driver interfaces with a driver called the miniport. The miniport driver is designed by the hardware manufacturer to work with a specific adapter and is responsible for taking requests from the port driver and sending them to the target logical unit number (LUN). The port driver calls the HwStorStartIo( ) function to send requests to the miniport, and the miniport will send the requests to the LUN. When the request is complete, the miniport will call StorPortNotification( ) with the NotificationType parameter value set to RequestComplete, along with a pointer to the completed SRB.
FIG. 2 is a block diagram of a virtual desktop infrastructure (VDI) environment 200 which can implement this type of functionality when a mass storage device is redirected from a client terminal 102 to a server 104 over a remote session. As shown, while client terminal 102 has established a remote session with server 104, a mass storage device 240 is connected to client terminal 102. In accordance with embodiments of the present invention, client terminal 102 can be configured to redirect device 240 over the remote session so that the device is accessible on server 104. Proxy 210 on client terminal 102 and agent 250 on server 104 can be configured to establish and maintain the remote session to enable this redirection.
FIG. 2 provides a general overview of the primary components that can be employed to redirect mass storage device 240 at the disk level. This technique can be referred to as disk level redirection and is distinguished from general USB redirection in that the redirection occurs at the disk level rather than at the USB device level. In particular, client terminal 102 can include a disk driver stack 220 that includes a disk driver 220a, a USB storage driver 220b, and a USB hub driver 220c. As is known in the art, USB storage driver 220b and USB hub driver 220c can implement the USB protocol to enable communication with device 240 as a USB mass storage device. Disk driver 220a, which in some embodiments may be an instance of the disk.sys process, can function to service read/write requests and to abstract the underlying USB storage and hub drivers 220b, 220c. 
When mass storage device 240 is connected to client terminal 102, disk driver 220a may be configured to report the presence of device 240 to proxy 210 and to provide the device information (e.g., device descriptor) to proxy 210. Proxy 210 may be configured to report the presence of device 240, along with the device information, to agent 250 of server 104 over network 106. Thus, disk driver 220 redirects device 240 to server 104 via proxy 210.
Agent 250 may be configured to receive the report from proxy 210 that device 240 is connected to client terminal 102 and the device information. Agent 250 may further be configured to associate with the report from proxy 210 one or more identifiers for client terminal 102 and/or for a user session through which client terminal 102 is connected to server 104, such as a session number or a session locally unique identifier (LUID). Agent 250 can provide notification of device 240, along with the device information, to virtual disk enumerator 260. Virtual disk enumerator 260 may be configured to create and store in memory a record corresponding to device 240, the record including at least part of the device information and session identifiers received from agent 250. Virtual disk enumerator 260 may be configured to report to operating system 170 of server 104 that device 240 is connected and to provide the device information to the operating system. This allows the operating system of server 1204 to recognize the presence of device 240 even though device 240 is connected to client terminal 102.
Based on the device information, operating system 170 may load a corresponding disk driver 282, which may be another instance of the disk.sys process, which may sit below a file system stack 280 to receive and convert file system requests to disk requests (e.g., by creating a CDB and embedding it in an SRB) and to pass these disk requests (e.g., IRPs and associated SRBs) to virtual disk enumerator 260 at the bottom of the device stack. It is noted that a volume manager is not shown in this figure for simplicity. Virtual disk enumerator 260 functions to virtualize mass storage device 240 on server 104 (as represented by virtual mass storage device 290). This virtualization is accomplished by routing the disk requests to agent 250 which will forward them over the remote session to proxy 210, down through disk driver stack 220, and to mass storage device 240 where they can be fulfilled. Corresponding responses can then be routed in a reverse direction towards virtual disk enumerator 260 and up through disk driver 282, file system stack 280, operating system 170, and ultimately to an application 270 that originated the request.
It is to be understood that an IRP itself is not transferred between proxy 210 and agent 250 (since much of the IRP is server-specific (e.g., pointers) and would therefore be meaningless on the client). Instead, sufficient content of the IRP is transferred from agent 250 to proxy 210 to allow proxy 210 to recreate (or to cause to be recreated) an equivalent IRP on the client side. A similar process is employed when proxy 210 returns results of handling an IRP.
When UASP devices are connected to a computer, they can advertise various parameters that can be used by the computer when transferring data to the devices. For example, a UASP device can maintain a MAXIMUM TRANSFER LENGTH parameter which specifies the maximum transfer length in blocks that the device accepts for a single command as well as an OPTIMAL TRANSFER LENGTH parameter which specifies the optimal transfer length in blocks for a single command. Transfers that exceed this optimal transfer length may incur significant delays in processing due to the architecture of the device. Accordingly, the operating system may query a UASP device for such parameters in order to optimize commands it may send.
In a redirection scenario, however, adherence to these parameters may actually hinder performance. For example, although the OPTIMAL TRANSFER LENGTH may be optimal for the UASP device, it may not be optimal for transfer over a network. Therefore, employing the OPTIMAL TRANSFER LENGTH for a redirected UASP device may result in large network overhead. For example, if 64 KB of data needs to be written and the OPTIMAL TRANSFER LENGTH is 4 KB, the operating system on the server may generate 16 different writes of 4 KB each. Each of these 4 KB writes would then be individually transferred over the network to the client with each transfer incurring overhead (e.g., compression, deduplication, etc.). The end result is that the write of the full 64 KB will take much longer. To avoid this additional network overhead, the operating system could be configured to employ the MAXIMUM TRANSFER LENGTH rather than the OPTIMAL TRANSFER LENGTH. Although doing so will reduce the network overhead, it will not be optimal for the UASP device. In addition to the delays that may result while the UASP device handles the less than optimal transfer length, using the MAXIMUM TRANSFER LENGTH will likely cause the UASP device to fail sooner than if the OPTIMAL TRANSFER LENGTH were employed. For these reasons, when a UASP device is redirected, many of the benefits that the UASP provides are lost.